Skip to content

Conversation

@boosik-sol
Copy link
Contributor

@boosik-sol boosik-sol commented May 9, 2025

This PR is implementing transfer_locked_position instruction in ts-sdk.

  • implementing instruction
  • unit test
  • testing in devnet, mainnet

@boosik-sol boosik-sol force-pushed the boosik/impl_transfer_locked_position_ts_sdk branch 2 times, most recently from 4664190 to 7af6810 Compare May 9, 2025 08:11
}
});

const testTransferLockedPositionInstructions = async (
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intended to test following

  1. position owner opens new position
  2. lock it
  3. try to transfer locked position
  4. after transfer, verify if position is exsit, and locked.

@boosik-sol boosik-sol force-pushed the boosik/impl_transfer_locked_position_ts_sdk branch from 7af6810 to 1ca7fcd Compare May 9, 2025 09:01
@boosik-sol
Copy link
Contributor Author

No lockPosition test code, so need to test it first.

@boosik-sol boosik-sol force-pushed the boosik/impl_transfer_locked_position_ts_sdk branch from 097394e to 757b2b3 Compare May 10, 2025 15:29

for (const poolName of poolTypes.keys()) {
for (const positionTypeName of positionTypes.keys()) {
const positionNameTE = `TE ${poolName} ${positionTypeName}`;
Copy link
Contributor Author

@boosik-sol boosik-sol May 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question) It seems if we open position with setupPosition(not supporting token extension), we couldn't lock position because it's token mint will be legacy SPL.
Are there any possible effects in real service? Like, if users open their position with open_position_instruction (not open_position_instruction_with_token_extension, they might not be able to lock position.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't there a setupTEPosition function?

Copy link
Contributor Author

@boosik-sol boosik-sol May 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yap, I tested only positions made with setupTEPosition. But what I am wondering is that if we need to support lockPosition with position made with setupPosition. This case was failed. (So I didn't add this case.)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend that. we should have a test case to verify that non-TE tokens cannot use transfer lock just to be complete.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added!

@boosik-sol boosik-sol force-pushed the boosik/impl_transfer_locked_position_ts_sdk branch 2 times, most recently from 5377182 to 0e7cff2 Compare May 10, 2025 17:04
Copy link
Member

@wjthieme wjthieme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there! Couple of small comments left

@@ -0,0 +1,154 @@
import { describe, it, beforeAll } from "vitest";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this from the other PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I include lockPosition test case in this PR. Because lockPosition and transferLockedPosition share same logics, but there is no lockPosition test code.

tokenProgram: positionMint.programAddress,
});

const lockConfigPda = await getProgramDerivedAddress({
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wjthieme Could we use this with @orca-so/whirlpool-client? I think it is not exported. Or, I will move this to utils.ts when I fix lockPosition.ts

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah if the function is not yet in @orca-so/whirlpool-client (or not exported) feel free to add/change it there!

@boosik-sol boosik-sol force-pushed the boosik/impl_transfer_locked_position_ts_sdk branch 2 times, most recently from 60750f4 to b3efc44 Compare May 19, 2025 15:35
Comment on lines +146 to +240
for (const poolName of poolTypes.keys()) {
for (const positionTypeName of positionTypes.keys()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we try to use test.for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are several codes using this pattern, so how about fix them together?


for (const poolName of poolTypes.keys()) {
for (const positionTypeName of positionTypes.keys()) {
const positionNameTE = `TE ${poolName} ${positionTypeName}`;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend that. we should have a test case to verify that non-TE tokens cannot use transfer lock just to be complete.

["one sided B", { tickLower: 1, tickUpper: 100 }],
]);

describe("LockPosition instructions", () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest we add more test cases to cover all the parameter that this function takes in:
ex:

  1. receiver (self vs un-related wallet)
  2. authority (funder vs another wallet that owns the position vs another wallet that doesn't own the position)
  3. position mint types (TE vs non-TE) ✅
  4. position lock state (locked vs unlocked) ✅

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make more tc about case 2, but could you describe more about case 1? is there receiver in lock-position?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to clarify, this function takes in the receiver as where the locked position can be transferred to. Assuming walletA owns the locked position today, edge cases are:

  1. What if walletA sets walletA as receiver? (tries to send to self)
  2. walletA -> walletB (normal case)

@boosik-sol boosik-sol force-pushed the boosik/impl_transfer_locked_position_ts_sdk branch 2 times, most recently from afb9132 to 222c93e Compare May 28, 2025 14:05
@boosik-sol boosik-sol force-pushed the boosik/impl_transfer_locked_position_ts_sdk branch from 222c93e to c59ceda Compare August 11, 2025 12:08
Copy link
Collaborator

@yugure-orca yugure-orca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you apply the following two changes?
The PR has been open for a while, so I’d like to make only these changes and then merge it.

  • Export lockConfig.ts in ts-sdk/client/src/pda/index.ts and (PR1034 did it) use getLockConfigAddress to derive lock config PDA.
  • Add an instruction to idempotently initialize the destinationTokenAccount (ATA).

Since @orca-so/whirlpools provides high-level functions, it will create required ATAs. However, transfer_locked_position instruction does not initialize the destination in the instruction itself, so I think it’s better to provide an ATA initialization instruction on the client side.

Regarding test cases, scenarios blocked at the contract level (e.g., non-TE positions cannot be locked or transferred) are already covered in the legacy-sdk integration tests.
(There’s no need to remove them.) It’s not mandatory for ts-sdk tests to verify that the contract rejects these cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants